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REMARKS 

Claims 21-35 have been canceled. Claims 1-20 are now pending in this application. 
Reconsideration of the application is earnestly requested. 

Applicant respectfully submits that the above amendments to the claims address the 
Examiner's objections under section 1 12. 

The Examiner has rejected claims 1-35 under section 103 as being unpatentable over 
Tushie *al. (Tushie) in view of Morris. Although the Examiner's arguments have been 
carefully considered, Applicant respectfully traverses these rejections as explained below. 

The Presen t Invention 

As pointed out in the background of the invention, the chip card personalization process 
is c U rrently quite complex. There may be over forty chip data elements that need to be 
incorporated into the card personalization process. Also, the interdependency of the data 
elements make the process of defining these elements more complex. In the prior art, 
programmers needed to know complex details in order to manually create a data preparation 
tabic of values (i.e.. a personalization data file) that would be used to personalize the card with 
various options that a card issuer desired. Because this was a manual process it was error-prone. 
The present invention addresses these problems by providing a technique of automating the 
personalization of a batch of smart cards. 

A technique is provided that assists a user with deciding which particular smart card 
feature* should be programmed into a batch of smart cards. In the early years of smart card 
personalization (such as that described by Tushie below) the process was far simpler as typtcally 
there was a single application to be programmed onto the card and a set of cardholder data to be 
programmed. At the time of the present invention, however, due to domestic and regional 
market needs, increased fraud protection, risk management, other business decisions, etc., an 
issuer has a large number of smart card features that need to be programmed onto the card. In 
the early years the option of including these features did not exist and therefore no systems 
provided the capability to personalize these features. 

The present Specification provides clear examples of what is meant by the term "smart 
card features- as used in the claims. Beginning at page 18. for example, smart card features 
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include- account data (e.g., where a card may be used, a default application, foreign language 
support, application priority, and card expiration risk management); off-line authorization 
control (e.g., risk management, amount limits, velocity checking, and card effective date 
decisions); card verification methods (e.g., types of methods and international applicability); risk 
management decisions (e.g., action taken if verification not successful); data authentication 
(e g static or dynamic and risk management decisions); card authentication options (e.g., 
cryptogram used); issuer authentication options (e.g., optional or mandatory); issuer script risk 
management decisions; and tow value payments (e.g., how implemented). 

Thus, "smart card features" as used in the claims are not simply cardholder data (such as 
a cardholder 1 '* name or account number), and are not personalization equipment commands. 
Rather, "smart card features" are high-level smart card management instructions dictated by the 
smart card issuer that tell a smart card how it should behave in numerous situations such as 
authorization, cardholder verification, ATM usage, fraud detection, payments, etc. 

The Cited Ar^TWinpuished 

Tushie, by contrast, does noi disclose personalizing smart cards with "smart card 
features" as required above, mainly because at the time of the invention of Tushie, there were no 
complex smart card features that needed to be added to smart cards. Throughout the disclosure 
of Tushie, there is no mention of the required smart card features, only data formats, card 
software applications, operating system commands, cardholder data and personalization 
equipment commands (see Abstract). 

For example, Figure IB only shows ihat cardholder data 152 are fed into the smart card 
personalization system. Figure 8 discloses that data templates, equipment characteristics, 
operating system commands, and cardholder data are acquired. Further, Figure 13 discloses card 
application data such as files, various fields, and the name of the software application. But, these 
are not smart card features as required by the claims that are high-level card management 
instructions. 

Other portions of the specification of Tushie also do not disclose the required smart card 
features. Column 1 at lines 54-58 disclose that the personalization information used is simply 
the cardholder's name, account number, expiration date and a photograph. Column 2 at lines 38- 
67 disclose that the database of the personalization system includes application data, template 
data, operating system data, and personalization equipment data; none of these are high-level 
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smart card management instructions. Column 3 at lines 35-62 also disclose similar types of data. 
Column 4 at lines 8-10 disclose that a data format element is simply a template for the 
personalization data. Column 4 at lines 44-47 disclose that the information transferred to a smart 
card is cardholder data and smart card software applications. Column 6 at lines 29-33 disclose 
that the personalization information is simply traditional cardholder data. Column 6 at lines 40- 
63 disclose that the smart card personalization system transfers data to personalization equipment 
that include data for cards and card operating systems, card applications and personalization 
equipment. Column 7 at lines 40-48 disclose the various types of cardholder data that are 
transferred. 

Independent claims 1 and 1 1 of the present application require a " member profile having 
HrfanlT values fo r gaga £gg futures, " "queries regarding said smart card featuiga," and "output 
A«t* values of said penalisation rtta file used to nrovide said smart card featur es." As 
explained above, the smart card features are high-level smart card management instructions that 
allow a smart card to operate in any environment as if the issuer were exerting direct control. 
Tushie only discloses traditional cardholder data, data templates, personalization equipment 
commands and characteristics, and software application data that are transferred to a smart card. 
Tushie does not disclose the required smart card features because at the rime of the invention of 
Tushie, the state of the art of smart card personalization had not advanced to the point where it 
was necessary to personalize a smart card with a complex variety of high-level smart card 
management features. 

The Office Action relies upon column 6, lines 40-46 as disclosing a system that receives 
smart card feature information. But, as previously explained, the smart card personalization 
system 100 is receiving data such as cardholder data, data templates, personalization equipment 
commands, ct cetera. This low-level type of data is not the high-level smart card management 
instructions that are the required smart card features of the independent claims. 

Further, because Tushie does not contemplate high-level management instructions being 
needed for personalization, there is no disclosure of a user receiving queries regarding which 
smart card features to implement, nor disclosure of a user providing answers to those queries 
regarding which smart card features to implement. 
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Reconsideration of this application and issuance of a Notice of Allowance at an early date 
respectfully requested. If the Examiner believes a telephone conference would in any way 
expedite prosecution, please do not hesitate to telephone the undersigned at (612) 252-3330. 



are 



Respectfully submitted, 

BE^ER WEAyE£j& THOMAS 




Jonathan O. Scott 
Registration No. 39,364 




Beyer "Weaver & Thomas, LLP 

P.O. Box 778 

Berkeley, CA 94704-0778 

Telephone: (612) 252-3330 
Facsimile: (612)825-6304 
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